home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 15840 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.6 KB
  1. Path: solon.com!not-for-mail
  2. From: seebs@solutions.solon.com (Peter Seebach)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 8 Apr 1996 07:59:20 -0500
  6. Organization: Usenet Fact Police (Undercover)
  7. Message-ID: <4kb2j8$an0@solutions.solon.com>
  8. References: <JSA.96Feb16135027@organon.com> <dewar.828879781@schonberg> <4k9qhe$65r@solutions.solon.com> <dewar.828936837@schonberg>
  9. Reply-To: seebs@solon.com
  10. NNTP-Posting-Host: solutions.solon.com
  11.  
  12. In article <dewar.828936837@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
  13. >Peter said
  14. >"Now, as it happens, Linux does do the right thing - if I define my own
  15. >read(), I get *my* read any time I call read, so the implementation is
  16. >conforming."
  17. >Boy, this sure has wandered!
  18.  
  19. True enough.  The above is the only ANSI related issue.
  20.  
  21. >THe original issue was the semantic behavior
  22. >of read. Unlike other unices, in Linux, the bounds check for the read
  23. >buffer is based on the requested count, rather than the actual count
  24. >of data bytes read. It is hard to say either approach is right or
  25. >wrong, but they are different enough to cause portability problems.
  26.  
  27. How?  No offense meant, but any code which can be affected by this is flat
  28. out broken.  POSIX-style read is to be given a pointer to at least nbytes
  29. of space, for the information read.  Period.
  30.  
  31. No correct code can ever be affected by the behavior of read when nbytes
  32. is larger than the size of the buffer.  (For latecomers, the question is
  33. what happens if you *KNOW* that the file only has, say 100 bytes left, so
  34. call read with a 100-byte buffer, and nbytes==256.)
  35.  
  36. I can't see how this is a "portability problem" any more than it's a
  37. portability problem that some systems will crash on
  38.     printf("%s", (char *) 0);
  39. ... (SunOS won't, though.)  Something which works only on some systems is
  40. not a portability problem *if there is no standard saying it works*.  Likewise
  41.     i = ++i;
  42. producing different results on different machines is not a "portability
  43. problem".
  44.  
  45. If read() behaved dramatically differently with valid inputs, I would see it
  46. as a portability problem.
  47.  
  48. (This applies to most of the C standard library, as well, of course.  The
  49. behavior you're used to, such as "void main(void)" or "fflush(stdin)" not
  50. working, is not a portability problem, it's broken code.)
  51.  
  52. -s
  53. -- 
  54. Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
  55. C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
  56. FUCK the communications decency act.  Goddamned government.  [literally.]
  57. The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html
  58.